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Abstract 

We provide an overview of the Stanford How Things Work fHTWt „„ 

integrated collection of research activities in the Knowledge Systems Yaboratoi^ af^ 
Stanford University. The project is developing technology for representing knowledge 
about engineered devices in a form that enables the knowledge to b» used in mXle 

knowl^dve^h r eaS , 0nmg tasks ’ and reas »ning methods that enable the represented 
knowledge to be effectively applied to the performance of the core engineering lask of 

simulatmg and analyzing device behavior. The central new capalS^^^rS^behur 

Xf cattXt “‘““f 4 * 1 3SSistance With model Emulation and with & 

Ipeciffcation electr °- mechanic ^ device satisfies its functional 


Introduction 


Pr tt ‘ S a " 0,lg0ing “U«tion of research 

by Rmhard F'kes. The overall objective of the project is to develop knowledge-based 

Xmnetenrel W K "° mputer systems to offe r intellectual assistance at high levels 
^ ? Pr ° bl ' m S0lvers and decisi °n makers in all stages of the life cycle of 

engineered products. To achieve that objective, we are developing: 

' JX n0l T l° r re P r f sentin e knowledge about engineered devices in a form that 

enables the knowledge to be used in multiple systems for multiple reasoning tasks, and 

• Reasoning methods that enable the represented knowledge to be effectively applied to 

beh. P ^~ ° f the C ° re enStinee ™ 8 task ° f and anaS device 

The knowledge to be represented includes a broad range of subjects from the 

hehav menta !i f pbyS1CS and engineering, to device models that describe device structure 
behavior, and function, to the rationale for the design of specific devices In o der to 
directly support the reuse of encoded engineering knowledge bases we are worX with 
o er research groups to establish a common device modeling language and a clearing 
house for device models. The common language will be based on and make usetf^ The 

[NeX etal 91] g deVel ° ped in the DARPA Knowledge-Sharing Initiative 
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The primary engineering task on which we are £ Editing Z^nXtmg 
electromechanical devtces , by fetology has the 

" ey 

during £ eariyX" of design, since the detailed design specifics required to do 
conventional numerical simulations are not yet available. 

“SaSS^HsssH^' 

simulations on an as-needed basis to answer specific analysis question . 

. Self interpreting - In order for designers to use simulators for multiple purposes on a 

saasssss* • 

oriented to a given analysis task. 

interpreting. In particular, we are developing techniques for. 

• ™ 

analysis task, 

analysis task, 

. Automatically guiding a aimulater to consider scenarios that are relevant to a gtven 
analysis task, 

. Generating human-understandable consul explanations of simulation results, 

. Automatically determining whether simulated behavior satisfies functional 
specifications, and 

. Testing and automatically generating procedures for operating the device. 
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sufficient level of maturity to provide both a demonstration vehicle and a useful 
experimental testbed within the project. 

DME is intended to enable a designer to document a design as it evolves and to support 
experimentation with alternative designs. The current system is used as follows: 

• Designer describes device - The designer selects components from a library and 
specifies the structural connections among the components. 

Designer selects behavior models - The designer selects from a library the models of 
component behavior that provide the abstractions, approximations, assumptions, and 
perspectives which are appropriate for the analysis he or she wants to do. 

• DME generates simulation model - DME uses the device model specified by the 
designer to generate a qualitative or quantitative simulation model of the device . 

• Designer ■interactively guides the simulation - The designer uses a simulator 
provided by DME to interactively explore possible device behaviors . 

• DME provides causal explanations of simulated behavior. 

Designer analyzes behavior - The designer compares the predicted behavior with the 
intended functionality of the device. 


New Capabili ties Being’ Produced 


The current DME system embodies state of the art research results. It provides an 
integrated set of tools for performing what might be characterized as a limited form of 
semi-automatic behavior analysis. For example, the system automatically formulates a 
simulation model, but only after the designer has selected from the system's model library 
appropriate behavior models for each device component. 


Our current research is focused on taking steps toward providing a designer with a 
comprehensive and fully automated behavior analysis of a device being designed. Our 
three year goal is to develop new capabilities and integrate them into DME so that the 
system could be used as follows: 


• Designer describes device - In addition to the current facilities for selecting 
components from a library and specifying the structural connections among the 
components, new facilities will be developed to enable the designer to specify: 

• Intended functionality of a device, 

• Expected operator interactions with a device, 

• Assumptions about the environment in which a device will be operating, and 

• Rationale for design decisions; 

• DME formidates appropriate behavior model - New facilities will be developed that 
will enable DME to determine the abstractions, approximations, assumptions, and 
perspectives that are appropriate for specific analysis tasks such as testing whether the 
device design satisfies the functional specifications. 

• DME generates appropriate simulation model ~ DME will use the structural and 
behavioral device models to generate a simulation model of the device that intermixes 
qualitative and quantitative simulation as needed. New facilities will be developed to 
enable it to select an appropriate qualitative or quantitative simulator for each device 
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module depending on the level of detail at which the module has been designed and the 
level of detail required by the analysis task. 

. DME guides the simulation - New facilities will be developed to enable DME to direct 
the simulator to consider scenarios that are relevant to a given analysis goal such as 
testing whether the functional specification is satisfied. 

• DME determines whether behavior achieves the intended functionality - New 

facilities will be developed to enable DME to compare the simulated behavior with the 
functional specification. In cases where the behavior does not satisfy ' * e 
snecifications DME will be able to provide feedback in the form of additional 
constraints”^ the design which would guarantee that the device behaves as .-tended. 

. DME explains behavior analysis results - In addition to the current faciUties ; for 
providing causal explanations of simulated behavior, new facilities wil ^be developed 
to explain how and why the design either does or does not satisfy the functiona 
specification. 

An additional significant capability being developed in our project which is not 
highlighted in the above scenario is the use of DME for design, ng and analysing 
procedures for operating a device. For example, DME seems particularly useful for 
assisting with the verification of procedures that respond to device malfunctions in that it 
eimbles^imulation models to be rapidly reformulated to reflect ™a^“tion, ard can 
explain the effects caused by the procedures. We are currently working with NASA on 
such a procedure verification application in which DME will be used for both proce ure 
debugging and operator training. 

The central new capabilities currently being developed for DUE are ; 
with model formulation, automated assistance with verification that a design sahsf 
functional specification, and automatic generation of causal explanations o 
behavior. Our approach to achieving these capabilities is summarized in the sections 

below. 


Automatic Model Formulation 

We are developing methods for providing automated assistance with the core problem of 
IS taS - a service that will help engineers build uontnvral models of devrce 

behavior for specific purposes. 

The state of the art in model formulation today is model configuration from libraries of 
MmponentmodeU. Simulators such as SPICE [Kattenelsou 66) and «,ose or VHDL (Harr 
and Stanculescu 89] are based on libraries of component models which have been 
^£5, modeling experts. The user selects components and conflgutes them, 
and then the system compiles the code necessary to run a simulation and plot the 
trajectories of variables. 

Today's component-based model libraries are most successful in those domains where 
components are well-defined idealizations at a single level of abstraction, such aB logics 
circuits The mapping between physical components and idealized component models 
simple and there is exactly one behavior model associated with each component model. 
S&HSSU purt of the model formulation task is shnplified in that he or she need 

only specify a component connection topology. 

However in most domains and tasks, the mapping from phenomena of interest in a 
physical system to a set of possible behavior models is complex and the result of nontrmal 
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reasoning. In doing model formulation, an engineer must identify the relevant 
abstractions to model, deciding, for example, whether to treat the load of an electrical power 
supply as a single resistive element or as a system with components that vary in their 
power usage. The engineer must also make simplifying assumptions and 
approximations , such as to assume no friction in a gear train or that a valve can be 
modeled as a discrete switch. The engineer makes these modeling choices to produce a 
model which answers a particular information need in a reasonable amount of time. 


The power of the library approach derives from the reuse of the component models and the 
automatic assembly of system models from partial descriptions. DME will achieve the 
same advantages of knowledge reuse and automation, but for a more general class of 
domains and for multiple modeling purposes. 

Even in domains such as analog circuits where there is a large library of ready-made 
simulation modules for standard components, building a model of an entire system is not 
an easy task. There are typically many simulation modules for each type of component, 
each based on different simplifying assumptions and approximations which are not stated 
explicitly. Therefore, a significant amount of effort and expertise is required for 
engineers to use even off-the-shelf simulation modules to assemble a model of a whole 
system. Engineers often prefer to write their own modules instead of using off-the-shelf 
modules precisely because they do not know all the underlying assumptions and do not 
trust their results. 

DME will enable knowledge reuse by providing the representation and architecture for 
model libraries containing a comprehensive body of behavior model fragments, each 
making particular abstractions and approximations and conditioned on explicitly 
represented modeling assumptions. The formalism and examples will allow engineers to 
fill the libraries with model fragments covering those phenomena they need to model. We 
expect that a market will develop for these models, possibly driving a small industry of 
component-model-building specialists (as in electronics). 

DME will provide automated model formulation assistance using these libraries. The 
assistance will change the nature of the interaction between the human engineer and the 
computational environment. Instead of operating at the level of equations or fixed-level 
component models, the engineer may specify the high-level device structure, the 
simulation goal, the utility criteria, a description of the context of use, and any initial 
conditions. The system will take an active role in selecting appropriate model fragments 
to construct a complete and coherent simulation model. This advance in model 
formulation is similar to the improvement in software development from early assembly- 
language programming to Fourth Generation Language environments. 

Automatic Behavior Verification 

Understanding the design of an engineered device requires both knowledge of the general 
physical principles that determine the behavior of the device and knowledge of what the 
device is intended to do (i.e., its functional specification). However, the majority of work 
in model-based reasoning about device behavior has focused on modeling a device in 
terms of general physical principles or intended functionality, but not both. For example, 
most of the work in qualitative physics has been concerned with predicting the behavior of a 
device given its physical structure and knowledge of general physical principles. In that 
work, great importance has been placed on preventing a pre-conceived notion of an 
intended function of the device from influencing the system's reasoning methods and 
representation of physical principles in order to guarantee a high level of “objective truth” 
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in the predicted behavior. In contrast, in their work based on the FR (Functional 
Representation) language [Sembugamoorthy & Chandrasekaran, 1986] [Keuneke, 1991], 
Chandrasekaran and his colleagues have focused mostly on modeling a device in terms of 
what the device is intended to do and how those intentions are to be accomplished through 
causal interactions among components of the device. 

Both types of knowledge, functional and behavioral, seem to be indispensable in fully 
understanding a device design. On the one hand, knowledge of intended function alone 
does not enable one to reason about what a device might do when it is placed in an 
unexpected condition or to infer the behavior of an unfamiliar device from its structure. 

On the other hand, knowledge of device structure and general physical principles may 
allow one to predict how the device will behave under a given condition, but without 
knowledge of the intended functions, it is impossible to determine if the predicted behavior 
is a desirable one, or what aspect of the behavior is significant. 

In order to use both functional and behavioral knowledge in understanding a device 
design, it is crucial that the functional knowledge is represented in such a way that it has a 
clear interpretation in terms of actual behavior. Suppose, for example, that the function of a 
charge current controller is to prevent damage to a battery by cutting off the charge current 
when the battery is fully charged. To be able to determine whether this function is actually 
accomplished by an observed behavior of the device, the representation of the function must 
specify conditions that can be evaluated against the behavior. Such conditions might 
include occurrence of a temporal sequence of expected events and causal relations among 
the events and the components. Without a clear semantics given to a representation of 
functions in terms of actual behavior, it would be impossible to evaluate a design based on 
its predicted behavior and intended functions. 

While it is important for a functional specification to have a clear interpretation in terms 
of actual behavior, it is also desirable for the language for specifying functions to be 
independent of any particular system used for simulation. Though there are a number of 
alternative methods for predicting behavior, such as numerical simulation with discrete 
time steps or qualitative simulation, a functional specification at some abstract level 
should be intuitively understandable without specifying a particular simulation 
mechanism. If a functional specification language was dependent on a specific 
simulation language or mechanism, a separate functional specification language would 
be needed for each different simulation language, which is clearly undesirable. What is 
needed is a functional specification language that has sufficient expressive power to 
support descriptions of the desired functions of a variety of devices. At the same time, the 
language should be clear enough so that for each simulation mechanism used, it can be 
given an unambiguous interpretation in terms of a simulated behavior. 

An essential element in the description of a function is causality. In order to say that a 
device has achieved a function, which may be expressed as a condition on the state of the 
world, one must show not only that the condition is satisfied but also that the device has 
participated in the causal process that has brought about the condition. For example, when 
an engineer designs a thermostat to keep room temperature constant, the design embodies 
her idea about how the device is to work. In fact, the essential part of her knowledge of its 
function is the expected causal chain of events in which it will take part in achieving the 
goal. Thus, a representation formalism of functions must provide a means of expressing 
knowledge about such causal processes. 

We are developing a new representational formalism for specifying device functions 
called CFRL (Causal Functional Representation Language) that allows functions to be 
expressed in terms of expected causal chains of events [Vescovi, Iwasaki, Fikes, & 
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Chandrasekaran, 1993]. We are providing the language with a well-defined semantics in 
terms of the type of behavior representation widely used in model-based, qualitative 
sraulabon. Finally we are using CFRL as the basis for a function verification program 
which determines whether a behavior achieves an intended function. 


Explanation Generation 

We are developing a method for generating explanations of how devices work and 
incorporating that method in DME [Gruber & Gautier, 1992; Gruber & Gautier, 1993], On 
the basis of an initial device model and the behavioral predictions obtained through 

simulation DME can answer a range of user queries about the structure and behavior of 
the modeled system. 

The approach we are developing combines several techniques for explanation generation: 

• Automatically synthesizing formal mathematical models from high-level model 
specifications, and explaining low-level simulation data in terms of the original 
specifications 

Inferring causality from mathematical models, rather than assuming ad hoc, hand- 
crafted causal models 

• Dynamically generating explanations in response to user queries, which are 
formulated by direct manipulation on text and graphics displayed during simulation 

Supporting interactive follow-up questions, allowing the user to get more information 
on a particular point of an explanation 

u sing a compositional method of text generation, in which textual annotations of 
model fragments are composed into phrases, which are then processed to produce 
smooth, concise text. 

1116 explanations are intended for three application tasks: data interpretation, the design 
of operator procedures, and design documentation. The task of interpreting simulation 
data is important for exploring hypotheses about device behavior during conceptual design 
and for debugging the simulation model itself. Machine-generated explanations can 
facilitate data interpretation by showing the relationship between low-level simulation 
data and the original modeling decisions and assumptions. In the second application 
operators of equipment need to rapidly explore failure scenarios in order to design and test 
corrective procedures. Dynamically generated causal explanations can help the operator 
assess the situation and determine appropriate actions. Finally, self-explanatory 
simulations can be used to document design intent [Gruber, 1990; Gruber, 1991]. Instead of 
writing a static design document that is often inaccurate and out of date, the designer can 
demonstrate the intended and expected behavior of a device using simulation. The system 
can generate explanations in response to questions by the reader. 


An important element of the explanation approach in DME is the use of real engineering 
models, rather than ad hoc “causal models” that are built specifically for explanation 
generation. In explaining how things work, people do use causal terminology. However 
when analyzing the behavior of devices, engineers use formalisms such as logical and 
mathematical constraints that are not causal. DME infers causal dependencies among 
modeled parameters by analyzing logical and mathematical constraints. 


In DME, logical constraints occur in the preconditions of model fragments. Discrete 
events, such as changes in the operating regions of components or discontinuous changes 
in quantitative parameters, are due to changes in the activation of model fragments. The 
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“cause” of a discrete event, then, can be viewed as the set of faeU para^r^s 
satisfied the preconditions of a model fragment representing t ’ , , 

explain the cause of discrete events by describing how the preconditions of mode 
fragments are satisfied. It can then recursively explain the causal ancestry of eac 0 
facTor variatle values in the preconditions. This is similar to the trad, tmnal approach to 
explaining rule firings in expert systems. In DME, heuristics are applied to filter some 
the facts and variables, producing a more concise explanation. 

The collection of techniques we are developing constitute a practical method for generating 
interactive explanations of device behavior in natural language. No special knowledge of 
linguistics is needed for building models; the engineer merely annotates behavior mod 
developed for 'simulation. Because causal relationships are inferred for each isimulatmn 

scenario there is no need to build in assumptions of causality in the mod . 

modeling and simulation technology that underlies the approach is realistic for physical 
systems^that can be modeled with time-varying ordinary differential equations sue 
electromechanical devices for controlling position or force (e.g., ro mampu a or 
process control systems (e.g., control of fuel supply for the Space Shuttle). 
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